IBIS Macromodel Task Group Meeting date: 18 January 2022 Members (asterisk for those attending): Achronix Semiconductor: Hansel Dsilva Amazon: John Yan ANSYS: Curtis Clark * Wei-hsing Huang Cadence Design Systems: * Ambrish Varma Jared James Google: Zhiping Yang Intel: * Michael Mirmak Kinger Cai Alaeddin Aydiner Keysight Technologies: * Fangyi Rao * Majid Ahadi Dolatsara Ming Yan Radek Biernacki * Rui Yang Todd Bermensolo Luminous Computing David Banas Marvell Steve Parker Mathworks (SiSoft): * Walter Katz Mike LaBonte Micron Technology: * Randy Wolff * Justin Butterfield Missouri S&T Chulsoon Hwang Siemens EDA (Mentor): * Arpad Muranyi Teraspeed Labs: * Bob Ross Zuken USA: * Lance Wang The meeting was led by Arpad Muranyi. Randy Wolff took the minutes. -------------------------------------------------------------------------------- Opens: - Michael got an update offline from Walter about AMI root name checking. - Michael had a presentation to share on expanding Test Load and Test Data to support IBIS-AMI. ------------- Review of ARs: - -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the January 11th meeting. Michael moved to approve the minutes. Lance seconded the motion. There were no objections. ------------- New Discussion: Agenda item #6: Alphanumeric [Pin] names BIRD draft 2: Arpad reported the draft did not change from last week. Arpad noted Bob's AR was to check the function_table_group checking in the IBIS parser. Bob confirmed the parser does not check for alphanumeric characters only. Making the change in the BIRD will not lead to breaking old models. Randy commented he thought the BIRD looked good. Michael moved to submit the BIRD to the Open Forum. Randy seconded the motion. There were no objections. Arpad will submit the BIRD draft to the Open Forum [AR] Agenda item #7: BIRD Requiring clock-forwarded AMI data Rx models to return clock times Bob asked if the parser needs to enforce the new requirement in some manner. Arpad noted you would not be able to check for the desired behavior with the parser without exercising the model and checking its output. So there would be no change to the parser. Arpad noted this would be a help for the EDA vendors. EDA tools would not have to invent behavior that the model should be responsible for. Fangyi asked about the sentence "All clocked receiver models (which are accompanied by the reserved parameter Rx_Use_Clock_Input in their .ami parameter file) must return valid clock times.". What does it mean? Arpad described that we have SerDes models (traditional) and new clocked receiver models with a second clock input. He was trying to define the requirement is only needed for the new clocked models. Fangyi proposed shortening the sentence to "A receiver model that specifies the Rx_Use_Clock_Input parameter must return valid clock times." Arpad added this sentence to draft 4. Walter moved to submit the BIRD to the Open Forum. Michael seconded the motion. There were no objections. Arpad will submit the BIRD draft to the Open Forum [AR] Michael shared a presentation: [Test Load]/[Test Data] and AMI: Some Intial Thoughts [Test Load] defines the circuit, which is a simple circuit made of RLC elements and a simple transmission line. [Test Data] waveform keywords tell you what to expect at various points in the circuit and whether they are rising or falling data. You could relatively easily enhance [Test Data] to support IBIS-AMI. This would allow model-makers to convey the exact setup that works for them. This would save debug time. It would require more intensive AMI support by IBISCHK than exists today. There isn't an active simulation done by existing IBISCHK. Michael showed a pseudo-format for an AMI [Test Data] keyword. If we decide this is useful there are a lot of choices to make. There isn't much to change to support Tx models. For the Rx, we'd need to support a waveform location inside the buffer. Do we need to define success criteria beyond the waveforms? Supporting crosstalk might be a future discussion. Would we limit this to AMI_Init? Would we need to condiser updating [Test Load] to support IBIS_ISS and Touchstone interconnects? Arpad commented on the success criteria. We can check that clock times is monotonically increasing. Walter noted we are only checking the DLL. All you need for the AMI test data is to point to 2 files. One is the input to the AMI_Init function. The second is a file of results of the target, what the DLL should produce. They should be identical. We need to define a format of the contents of the input file. There is a CSV file format for testing that exists already and could be looked at. Michael noted he agreed there are only 2 files necessary. Walter noted the DLL doesn't care about near/far designations as currently described in [Test Data]. Ambrish asked what the point of [Test Data] for AMI is. Is it to validate EDA tools or validate the model? Michael noted it is to verify the model is working as the model maker delivers it but also to deliver additional information that is not part of the AMI defulats but is part of documentation that could not be automatically read. This also resolves the root name issue, which helps with debug. It shows a known good setup condition of the model. Arpad agreed it does confirm a known good operation of the model. Ambrish asked if the CSV input file format is something we would add. Michael noted you'd have to supply the impulse matrix and the output matrix. The question is how to structure the data. Fangyi asked what is the next step for determining the output of the model really does match what is supplied. What are the rising and falling waveform data doing? Arpad noted it would be beneficial to test the analog portion of the model, not just a DLL checker. Walter confirmed there would be one set of [Test Data] to test the analog portion and a separate set of [Test Data] to test the AMI portion. Michael is open to separate eveluations with different sets of data. Bob agreed we should separate the AMI testing from the analog testing. Fangyi noted it is difficult to understand what near and far mean in the context of AMI. Wei-hsieng asked about models that do no processing in AMI_Init. Michael noted that supporting AMI_GetWave would require additional thought and discussion. Wei-hsieng noted Ignore_bits adds complexity to supporting AMI_GetWave. Fangyi asked what could go wrong. What are we testing here? Walter commented it is a due diligence check that the parser could provide for model testing. Walter noted there may be difference in OS and rounding that makes the output file and the DLL output slightly different. Michael commented this gives the model developer a way to document a known good configuration of the model. Michael noted a Tx model is intended to point to a [Model] name. All the information will be there to say that the model with a certain setup works. Fangyi noted this could help model users to catch environment specific behaviors. Bob noted IBIS doesn't suport .csv format currently. Michael to send out his presentation to the ATM reflector [AR]. Walter asked Fangyi to review Walter's draft of BIRD211.4 [AR]. - Michael: Motion to adjourn. - Walter: Second. - Arpad: Thank you all for joining. AR: Arpad to submit the Alphanumeric Pins BIRD draft to the Open Forum AR: Arpad to submit the Clocked Rx AMI Models BIRD draft to the Open Forum AR: Michael to send out his presentation to the ATM reflector AR: Fangyi to review Walter's draft of BIRD211.4 ------------- Next meeting: 25 January 2022 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives